Subject: Real Resources

From: [email-masked] (Sanders, Ron)
Date: Tue, 15 Aug 1995 09:18:04 -0900

Gentlemen, thank you for your comments on the Resource Registration 
proposal. It contains the same high quality content and attention to detail 
that we have come to
expect from the people at DCL (Don't get suspicious, I'm just being 
courteous).

Before you begin reading my reply, I would like you to know where we are 
coming
from with this. I believe Dave Finnie will agree with these statements, if 
not, Dave please
chip in.

    o We believe this type of functionality is essential to the survival of 
APPN.

    o We view the proposal as just a starting point and believe that any 
eventual solution
        may not look even remotely like the original proposal.

    o Very few sacred cows are contained within the proposal. This implies 
that there are
        some, and indeed there are:

                   1) Registration of resource types other than LU should be 
supported.
                   2) A robust query capability should be provided.
                   3) Connection to resources by resource name should be 
provided.
                   4) Duplicate resource support should be supported.
      5) An API should be provided so that application programmers can 
access the
                        functionality.

Having said this, here are my replies:

> -  We think that the functionality the proposal is intending to provide
>   would be extremely useful and would help make APPN/APPC easier to
>   use (and more popular).

We agree. Beyond that, we believe it is essential to the survival of APPN.

> -  We worry that the proposal as it stands will not provide a migration
>   path for a network of non-upgraded nodes.

We agree, backward compatibility is a must! We do not believe the proposal
will stand in its present form. The proposal is just a starting point. Very
few sacred cows are contained within it.

> -  We think that the DS architecture makes it unsuitable for a lot of the
>   additional function the proposal introduces.

It appears that only minor changes are necessary to use DS for the purposes
outlined in the proposal. Given that, I am not sure I fully understand
why DS would not be the correct place to address this functionality.
However, as I said, no sacred cows.

>One of our main worries is with the impact of this proposal on a network of
>current-level NNs.  Our belief is that to make use of the current proposal
>fully, all the NN servers in the network would have to be upgraded.  The
>main
>reasons for this are as follows:
>
> -  The proposal suggests that the locate buffer size be increased to 32Kb.
>   We feel that this is far too large (and I will discuss this later) but
>   it will also cause interoperability problems.  If an NN tries to send a
>   current-level NN more data than 1024 bytes (the current limit) then the
>   receiving NN will not accept it (and may well bring down CP-CP sessions
>due
>   to the protocol violation).  This would cause particular problems if the
>   current-level NN was a route to a CDS (which could be expected to
>   return large amounts of data).
>

This would only be a requirement at the End Node were the locate/search
originated. Since the End Node would be a new implementation supporting this
functionality, this does not appear to be a problem. There is a 
corresponding
implication at the NN server. However, since the NN server would also be a 
new
implementation supporting this functionality, it does not appear to be a
problem here either. None of the intermediate nodes should be concerned
with this. Am I missing something?

> -  Much of the functionality provided by the proposal relies on multiple
>   (positive) responses to the "Locate/Find(CV3E)".  Current-level NNs will
>   react to the second positive reply not by forwarding it on but will
>   generate an alert to indicate a configuration error in the network (with
>   sense code 10100001).

>Following on from this, we have a fundamental worry about the way the
>proposal clashes with the way the DS algorithms have been designed to work.
>The introduction of the concept of multiple replies/multiple resources
>with the same name/wildcard searches.  The algorithms have been
>optimized to expect only single positive replies.

You have a point, however the concept duplicate resources is something that
must be addressed. Imagine how nice TCP/IP would be if you did not have
to specify the address of a DNS. You could just issue a gethostbyname and
any available DNS would reply with the hosts IP address. It would make 
TCP/IP
usable. This functionality would also make APPN usable. We cannot continue
to treat all duplicate resources as a configuration error, when some 
resource
types may lend themselves to duplication.

Having said that, lets get back to the subject. Since the NN server would
also be a new implementation supporting this functionality, this does not
appear to be a problem either. If the multiple positive replies contained
CV 3E's an alert would not be issued. If it contained only CV 3D then the
alert would be issued, just as back level nodes would do.

>Similarly the caching mechanisms will be useless with new proposal.  It
>seems that while making use of the DS mechanism for the proposal appears
>to leverage function, in actual fact much of it is given up.

Perhaps we should stipulate that replies containing CV 3E's would not need
to be cached?

>We also have a general worry about the proposal's interaction with CDS and
>Border Node.
>
> -  The proposal assumes that all resources are required to be registered
>   with a CDS.  Otherwise searching the CDS does not help, since you will
>   have to carry out a broadcast search in any case to discover any
>   unregistered resources.

Only resource of types other that LU, ENCP and NNCP would require this.
However, as you will note in the "Unresolved Issues" section, perhaps the
CDS should not be used at all?

> -  How will the proposal interoperate with BNs?  Will all LOCATE requests
>   be fanned out to all attached networks, or will some filtering take
>   place?

Good Point, this is an area not addressed by the proposal. Please provide
some recommendations.

>They could be submitted - as you say IBM has already made the 
specifications
>available.

True.

>That's true but providing this sort of function at an application level has
>several attractions as it
>
> - requires no changes to existing nodes (a better migration path)
>

Changes will be required, at the very least an API would have to be added
to existing implementations. ANAME would have to be developed or purchased
and integrated into existing platforms/implementations. Discovery would also
have to be developed or purchased and integrated into existing
platforms/implementations to make ANAME useful.

> - can be used by LEN nodes as well as APPN nodes
>

I was not aware that any of these back level nodes still existed. Bisync
protocols are still in use, but APPN does not attempt to address them (Just
a little jest from someone who spent a lot of time doing an End Node, 
actually
you have a good point).

> - will general cost less to implement, both in terms of development
>   costs and time to market.

This is a sweeping statement that leads me to wonder if you have a vested
interest in an ANAME solution? I would say that this depends on many 
variables.
See response to "no changes required".

>This problem could be solved (for example by using the Discovery
>architecture,
>or by adding the information to the topology database as for CDS).

True.

>Current NNs check to verify that a "CV3D" is present (and if not then
>generate the sense code 1014003D).  A dummy "CV3D" will need to be supplied
>with the "CV3E" in all flows to avoid this.

OK, CV 3D is required.

>This is not exactly the way registration will take place.  A NN does not
>wait
>until it has successfully registered with the CDS before positively 
replying
>to the EN.  Indeed it would also be prohibitively difficult to require the
>EN
>to wait until the NN has replied before returning the CMADDSRV verb - for
>example, what should happen if the EN has not yet established CP-CP
>sessions?
>
>This flow suggests that ENCP1 has CP-CP sessions to multiple NNs.
> Presumably
>you mean that NN1 will forward the "Locate/Cdinit/Find(CV3E)" on to NN2?
>
>Again, the CDS will then have to carry out (multiple?) directed searches.
>
>Again, the second Locate will be sent via NN1 ...
>
>and the response will returned via NN1.

Please do not pay to much attention to the flow diagrams, some of them were
put together late at night and contain errors. The intent was to provide
the reader with a rough idea of how the flows would occur, more work is 
needed.

>Does that mean that if an EN does not register including a "CV3E" then the
>NN will not allow it to make use of the new function?

I would say that if a 3E is not present then the registration request will
contain a 3D with a resource type of LU, ENCP or NNCP, just as it would 
today.
Both forms should be acceptable.

>At the moment, registration of resources with CDS is optional (and is
>specified on the registration request with the NN).  Are you suggesting 
that
>we surrender this capability?

This is only required for registration of resource types other than LU. No
changes for registration of resource types LU, ENCP and NNCP. Here again, we 

may not want to use a CDS at all. See "Unresolved Issues".

>Since with 1015 the EN receives the CP Capabilities of the NN before 
sending
>its own, it would be conceivable that an EN supporting the proposed 
function
>could check whether the adjacent NN also supported it, and if not request
>that it handle roadcast searches itself on its own Capabilities GDS.

It would be nice to detect this functionality before CP sessions are brought 
up
and perhaps even before the link is brought up. Discovery would do wonders
here.

>Aside from the interoperability problems I discussed earlier, this would
>place a tremendous burden on NNs.  To optimize performance and guarantee
>delivery an NN is required to preallocate space for all the LOCATE requests
>that it is handling.  Increasing the size of the buffer required to such an
>extent would cripple the LOCATE processing capabilities of the NN.

I do not understand why it would cripple an NN capabilities? I would tend to
believe that it would significantly enhance an NN's capabilities. However,
any and all alternatives solutions are welcome.

>Or indeed if the CDS does not know about the resource being searched for?

Agreed.

>The "best" resource to use cannot be determined without route computation.
>(For example, some resources may not be reachable with a particular COS.)

I do not believe this is true. Since all locate/locate replies flow at 
network
priority (all locates being equal that is), the first reply could be 
considered
to be the best at any point in time. A route calculation may occur (using 
the
specified Mode/COS) following the completion of the locate (depending on 
wether
the locate was connection or query driven). If the route calculation fails 
then
the next positive reply could be used to calculate a route (continuing until
a resouce was found that a route could be calculated to).

I do not believe that route calculation within APPN can ever guarantee the 
best
route (or resource) since networks are dynamic in nature. The best route (or 

resource) can change from moment to moment. APPN can only hope to make a 
best
guess based on available information (route resistance etc.).

>This is not entirely accurate.  As I mentioned earlier, when a CDS is
>queried for a resource, it will then perform a directed search to that
>resource (and the time of this directed search may well vary if a resource 
is
>further away).

Sounds reasonable.

---

From: [email-masked] (Sanders, Ron)
Date: Tue, 15 Aug 1995 09:29:21 -0900

Dave Finnie has authorized the posting of his response to the appn exploder. 
Since it is somewhere past midnight in Australia, we are posting it so the 
east coast folks can get a copy before they go home.
 ----------
From: Dave Finnie
To: Sanders, Ron
Cc: mcf; MIKE; njc; Allen, Michael; Ulrich, Miles
Subject: Re: Real Resources
Date: Tuesday, August 15, 1995 4:45AM

Ron/Matt,

In general I agree with Ron's comments completely. Here are some

>       that there are some, and indeed there are:

Totally agree on this point. I am not fixed to any particular
specifics to provide this function, but feel that the function, and
the objectives that you have outlined are essential to the continued
use of APPN (and our pay packets !).

> However, as I said, no sacred cows.

I also have problems working out why DS is not suitable for this
function. I have read the patents involved, and indeed it appears that
DS *was* originally designed to cope with this functionality, but the
architecture team determined that it was not necessary
immediately. Probably a good choice at the time, but it is time to
move on. I believe the patent architecture team were correct - this is
a function that is well suited to the current architecture. There are
also factions within IBM that would like DS expanded to perform this
function.

> with this. Am I missing something?

No, I think the guys at DCL have it right. Since the aim is to rely on
CDS to answer most queries, all NNs in the path between ONN and CDS
need to support large responses.

I was wondering if a workaround would be to "chain" locate messages in
some way that is transparent to intermediate NNs that only support
1024 bytes. I do believe that 1024 is very limiting, however. I think
an approach where a new CP capabilities field is defined that
indicates support of large(r) locate sizes should be used. Locates
would only be chained at the boundary of a large locate NN and small
locate NN.

> types may lend themselves to duplication.

As I said before, the DS algorithms *were* designed to return multiple
replies *and* multiple resources - even with the same name. I'm not
entirely sure why you have such a strong objection to this, Matt,
since I thought you guys had also gone through the patents ???

> Perhaps we should stipulate that replies containing CV 3E's would not need

Probably fair. I have a feeling someone in the architecture team might
have a good point of view on this.

> CDS should not be used at all?

I too have oscillated on my thoughts about using the CDS. While using
CDS still makes it necessary to send directed locates to each of the
resources that match the query, I believe this is still better than a
broadcast (especially since I think most queries would be quite
specific - ie avoiding wild-carding). So at the moment my feeling is
that use of the CDS is an advantage.

> Good Point, this is an area not addressed by the proposal. Please provide

I think that Ron and I are in the same boat here - we have very little
deep understanding of BN issues because IBM has hidden them to a great
degree, and we are both more EN oriented. Any advice you can give here
would be great.

> See response to "no changes required".

(and the rest of the ANAME stuff)

I do strongly agree with Ron on this one. The initial thing that hit
me in the face was that this was not an unbiased viewpoint. I take it
that you have at least begun developing ANAME ?

I know very little about ANAME, but it does appear to duplicate much
of the function of DS. This to me would indicate that it would cost
*more* for most people to implement, since rather than extending DS,
they would be duplicating it (and extending it).

> the reader with a rough idea of how the flows would occur, more work is

Yes, something that Ron and I never discussed but appeared to silently
agree upon was not to be too rigorous in what the diagrams
said. Perhaps this was a mistake. My feeling was that if the solution
changed dramatically they could all need reworking in any
case. However, your points on the diagrams are well taken - they are
not accurate.

> any and all alternatives solutions are welcome.

I do not understand either. I would have thought that if pacing were
performed in the architected manner, then RUs in the pacing windows
are the only ones that would need to be pre-allocated. Apart from
this, a control block is needed to track the locate, but this is
needed regardless of how large the locate size is.

Since the size of the pacing window is up to the receiver, and NNs
that are constrained in memory (ie small real memory only) will
typically have only a few NN-NN connections, surely the 32KB hit is
not too high ? In any case, I believe we can do a lot better than
1024.

> network priority (all locates being equal that is), the first reply
> could be considered to be the best at any point in time. A route
> calculation may occur (using the specified Mode/COS) following the
> completion of the locate (depending on wether the locate was
> connection or query driven). If the route calculation fails then the
> next positive reply could be used to calculate a route (continuing
> until a resouce was found that a route could be calculated to).
>
> I do not believe that route calculation within APPN can ever guarantee
> the best route (or resource) since networks are dynamic in nature. The
> best route (or
>
> resource) can change from moment to moment. APPN can only hope to make
> a best guess based on available information (route resistance etc.).

I think Matt is right. The application (TP) may specify a particular
MODE, which in turn specifies a particular COS. Just because we can
get back responses on the CPSVCMG COS connections does not necessarily
mean that a route exists to the resources using the TP supplied
COS. Irrespective of that, as Matt pointed out, the order of responses
using the CPSVCMG COS may be way off-beam in terms of the best
resource using the TP supplied COS. So I think route computation will
be necessary.

Dave

 ------ Message Header Follows ------
Received: from insession.com by msmail.walldata.com
  (PostalUnion/SMTP(tm) v2.1.5c for Windows NT(tm))
  id AA-1995Aug15.044539.1100.34989; Tue, 15 Aug 1995 04:45:41 -0900
Received: from elk.insession.com (elk.sydney.insession.com) by insession.com
(4.1/SMI-4.1)
     id AA14530; Tue, 15 Aug 95 05:41:12 MDT
Received: from wallaroo.sydney.insession.com by elk.insession.com
(5.x/SMI-SVR4)
     id AA08161; Tue, 15 Aug 1995 21:41:51 +1000
Received: (from dave@localhost) by wallaroo.sydney.insession.com
(8.6.9/8.6.11)
id VAA01447; Tue, 15 Aug 1995 21:44:26 +1000
Date: Tue, 15 Aug 1995 21:44:26 +1000
From: Dave Finnie <[email-masked]>
Message-Id: <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked],
        [email-masked], [email-masked]
In-Reply-To: <[email-masked]>
([email-masked])
Subject: Re: Real Resources

---

From: [email-masked] (Harry Silverstone)
Date: 16 Aug 1995 05:03:59 GMT

Hi,

      I will be out of the office until Monday, Aug 
28th, 1995. I will be checking my mail and will 
reply as soon as I can.

      If you need immediate assistance,  please 
contact either Matt Naugle or Adam Dunstan.

ThaR\[0

---

From: [email-masked] (Harry Silverstone)
Date: 16 Aug 1995 06:05:10 GMT

Hi,

Tha6
`